With the advent of IBM®'s DB2 Version 8, it became necessary for the Unicenter DB2 products to support Table-Controlled Partitioning (TCP.) It was decided that one of the design items for the project, in the effort to support TCP, would be to provide a means of modifying the partitions of a TCP table through interactive screens similar to those used for modifying partitions of an index object. One of the primary objectives was to provide and maintain symmetry between the two methods of altering partitions and their limit values—for both Table Controlled Partitioning (TCP) and Index Controlled Partitioning (ICP.) This, in turn, would facilitate their ease of use and provide some degree of intuitiveness to users already accustomed to and familiar with performing similar operations against index objects using the “Index Partitions Limit Key Values” screen.
Further, it was discovered that the most natural method of presenting the needed information pertaining to the arrangement of partitions, from the user's perspective, was to do so by always providing the orientation of an object's partitions in logical order rather than physical order. This is because it was also discovered that this is how DB2 manages the distribution of data across multiple partitions as it pertains to the ending values established or defined for each partition in a partitioned tablespace. By doing this, the user may more easily view and manage partitions and their ending values using the natural linear display of these items.
The difficulty in managing significant numbers of partitions, altering their ending values so that data may be redistributed at will—especially after a tablespace had been rotated—became quite apparent when it was further discovered that, although DB2 managed the data through the partitions using logical means, altering any physical attributes for any one, or number of partitions, required that it be done using only the partition's physical numbers rather than the more (seemingly) intuitive logical numbers.
Viewing partitions on interactive user screens showing only physical numbers can become a nonsensical jumble of seemingly non-contiguous physical partitions and physical partition numbering when presented and viewed using logical ordering (as compared to physical ordering, which would then adversely impact the presentation and ordering of limit key ending values in the same way, making them nearly, if not absolutely, impossible to understand and maintain). Since tablespaces may contain hundreds or thousands of partitions, it can become a daunting task, or be nearly impossible, to perform some simple tasks without grueling hours of manual analysis and research—and even then, there is no guarantee that the alterations and Data Definition Language (DDL) derived from such an effort will successfully execute the very first time because of the unavoidable element of human error.
Therefore, there is a need for a system and method to overcome the stated shortcomings of the prior art.